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Abstract . The paper advocates the need for sy s t ems which support 
maintenance of LISP-typer data bases, and describee an experimental system 
of this kind, cal fed DA0A. In this system, a description of the data 
base's structure la kept ip the data bi^Mc itself. A number of util Tty 
pro gr a mm U50 the description for operations on the data base, The 
description, must minimally include syntactic intormatTon reminiscent of 
d5ta Structure declarations in (pare conventional programm in.g 1 ahpuagen,,, 
and can be extended by the user. 

Tuo reasons tor such system** ar« sreifit ^ ] 3 As Ll. programs develop from 
toy do«Q I ns using toy data bases, to more realistic EKordofl, that 
management of the knowledge haaa becomes non-trlvial anrf requires program 
support- (23 A powerful u^y fig organize LtSP programs is to make them 
data-driven, whereby pieces of program are distributed throughout a data 
base. A data base managesent system Facilitates the use of this 
programming style. 

The paper describes and discusses the basic ideas in the DAEJA system as 
uel I as thfr techPlqUc Of data-driven programs. 
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1+ Focus on the delta base. 


(n this paper I will attempt (0 lay three things aL once. That stylistic experiment il undertaken 
not dlIL Of choice, but nut or neCHSIty; the? three topics arc intertwined, and rone C*r them car 
be discussed Without the content of the others. 

The first topic regards the atttfude fa daia I ihsll argue that (he current thinking about 

data bales in A.I. has mined an important point, which on be tersely characterized as the 
separate identity of IhE data base, independently of the progiam(s) that use it. 

The second topic is a corollary of the first one, namely the design of systems for mnnagtincnt of 
flat# fcam in the new sense, in the context of a LISP or LISP-1 Ike programming system, A 
very experimental management .system for L15P data bases is described. The system provides 
utility operations on the data base, such as data entry (prompt the uier for contributions to the 
data base), presentation (nice printouts) and backup (dump a part oF the data base cm a file). 
Additional utilities are planned. Alt Utilities Use a description of the data base’s structure, 
which is stored in the data base itself. The structure description muse minimally contain 
syntactic information similar to what one finds in data-StfUCtUrc declarations in conventional 
programming languages It can however be arbitrarily incremented by the user. Since it is in 
the data base, the description must itself have a description, which Ls also in the data base, and 
so on until a description which describes itself. 

This system (called DABA) is motivated partly by the practical problem of maintaining 
collection* of knowledge of non-trivial sue, foi use in A.I. programs, and partly by my 


preference foi : i certain progra.rnrning - slylc, which is here called dala-dnver programming. 
Orly a Throwaway implementation of DABA emits currently: the system cs described here in 
order to exemplify various desirable properties In systems for base management, and not as sir 
available fool. 

The method of pregrumming IS the third topic of the paper That programming 

technique is frequently used but rarely discussed; the reader who has already used it will 
recognize Lt by a common operation in data-driven programs, namely 
(APPLY (GET } ... I 

In other words, data-driven programs are those where large parts of the program are 
procedures or program fragments that are stored in the data base, in 3 less trivial sense than 
as EX PR proprtifls. The pstper argues for the use of this technique, This is relevant to (he 
Bata base topic because program management tools for dan-driven programs have (he same 
requirements as dan base management tools. In fact,, the distinction between 'program' and 
"data base' becomes funy and unimportant. 

The remainder of section: 1 attempts to spell out my view of data bases, and ihe idea that UtJlky 
programs arc an important tool For working with a data base in rhe new sense Section 2 
describes the banc description mechsniM in ihe DAB A system:, section 3 discusses data-driven 
programming in more detail; and section 4 discusses some simple procedure generation 
techniques in data-driven programs. 

One of che many defirtitjoni of 'daia base' In the world of commercial computing, is 'a 
collection of data which is suitable feu use by a variety of different programs 1 It is implicit in 


the definition that the data bast has an existence of its own, and a non-trivial life-length 
(although it may develop and change during its existence), The definition implies a need For 
separate dncumerttltlOTi and separate maintenance of (he data base. 

Thu view of the data base is significantly different from what one finds in A.i. In our field, 
the 'data base" has usually been an appends to or a Kr?tchpad area for the program., created 
during the computation, and Later garbage collected, or discarded at the end of the run. But 
the separate-identity view pf the data base is appropriate also in the A.I. context, in the 
following cases: 

- as the user-provided collections of knowledge I hat programs use. It has been common 
practice 10 use minimal knowledge bases when programs are rim (for several reasons 
including memory problem?) t but the Lime now seems ripe for working with more exhaustive 
collections of knowledge. The problems or setting Up, debugging, and editing the 
knowledge base then become non-tfl YJal. 

■ as knowledge generated by or reorganiied by programs, Learning programs (in the broad 
sense of The word) are only useful if the acquired knowledge can be saved for use during 
later runs. Ai another example, programmer's-apprentice-type programs [see e.g. Rich and 
Shrobe, 3Q"^J need to analyze the User's input program, and form a model of it. That model 
has to be maintained between runs. 

- a data-driven programs, Since programs have to be preserved between runs, it only makes 
sense to say that a program is a special case of a data base if the data base is so preserved. 

Let the [w-d kinds of data base bt called a 'scratchpad" data base (temporary data base during' 
execution of a program) and a 'perennial' data base (has separate ideality, separate 


documentation, etc., is ma in:a met; between runs, and is designed so that it can cofiv-ehicntly be 
Uttd by ptdgraim-ii. Tti fact, the difference is as much In the way of looking at SUnti 

working with the data baje, as m the design of the data ha:-: itself. 

The 'perennial' 01 'separate-identity' v^w of a data bast is very similar to the ordinary LISP 
programmers atutude to hii program. Workmg with a program does not merely involve 
running- It, bur also various typw of service -work: One may take out St part of the program 
and re-write it; one may take nut 4 pitbe of another program, adapt It, and insert it in one's 
own; one USAS pretty-print programs, Crass-tnde*m and Other tools, to obtaih readable listings 
and documentation for careful study of the program, and 40 forth. The very same operations 
on a data base come naturally when it develops to non-birkl SIM. 

j he major computational implication of the 'separate-identity" view of the data base is 
therefore the usefulness of Utility program. j, i.e. programs like pretty-printers and CfOSS- 
indoxers, which serve the user when he works with the data base, and which are usually called 
directly by the user, rather than as subroutines. Utility programs for operations on LISP 
programs are in common use, and can sometimes be used for data bases as well (such as pretry- 
printersk But a. number of additional utilities, as well as additional options in existing utilities, 
are useful for data base Operations. The following are utility operations which S have often 
wished I had had, when working with LlSP-type data bases, and which eaist or are planned 
in the DAB A system: 

“ 1 data entry utility that prompts the user for contributions to the data base. In a simple 
else, trucead of letting Lbe user type in 


(QEFPRQP BQSTflN J1A55 TN5TA7EJ 


{jn an elementary object-property representation), (ht sysient would acquire the inFortnuton that 
BOSTON is a city, and [hen prompt the appropriate properties by typing uut for example 
BOSTON ! INSTATE - 
whereupon the user can answer 
HASS 

Thr difference in convenience and error rate is of course negligible for the extremely small toy 
hoses that of[«n have been used m A 1. programs, but significant when one enters mare 
practical volumes Of data, - In. practice a good data entry utility must allow for higher-level 
data representations as well, for mixed-Jniitative dialogue, and for conversational conveniences 
such as 'undoing' [Teitciman, 19/i], 

'■ J 

“ a dumping utility for saving collections of data on files, if we again use an. example in the 
elementary object-property representation, (he filing Utility needs a catalogue of carriers (such 
as BflSjQN above} and information about which properiiES of this carrier shall be saved, and 
it Should generate a file which when read will re-create those properties. A baste facility of 
this kind exists in INTEH.LLSP [Tejtelmsiia, ]$7l], 

““ presentation utilities which print out the data haw or parts of it in a nice formar, SO 1 that the 
user can work wirh it easily. Severn! presentation method? are possible: an indentation- 
oriented, layout is reasonable when one prints properties which are suable expressions, and 
when when one wants to print properties or properties recursively to some dieplh. A tabular 
layDut with several columns is appropriate for atomic properties, and for relation-type data 
bases where the data base it a set of tuples Such presentation utilise? are similar to the 


dumper, except that they could also mate use of information about the Intended structure of 
properties, for example, if it ii known in a separate declaration that the property under a 
certain indicator J4 to be a lilt 'which will be used as a set, then an appropriate indentation 
strategy could be chosen, and one might sugar the printout with curly brackets, tf it is known 
that another property Ll a gwytm atom, then one might want to print it in terms of some of its 
properties, rather than as tts prininama, 

— a checking utility, to check thflt all propenies in a collection of data saiisfy the descriptions 
Thai have been made. On? can check against -declarations of the intended structure for each 
property (atom of certain type, list of atoms, etc.), against redundancy rules Of A t getple.l], 
then E C geipfAjD, and soon. 

“ 3 - merging Utility. -SupposE that travel cost beiwcen Cities has been represented as 
gotp [BOSTON, T'flAVELCQSTJ » EhYC [A] Ft 26,37 BUS 13.751 

TORONTO lklt\ 189.Ifl ...1 ,, + 3 

with the obvious anrerp relation (Boston ■ New York £ by air r etc.), and that one wanes To 
merge [wo files oF data with Jlmilar structure. If both Cites contain properties for the same 
carrierfindies.tor pair such as BOSTON/iRAYELCQST, then one must make the obvious merge of 
the two assigned properties, rather than let one overwrite The other, h fairly general utility 
program could do that If provided with structure declarations for properties. 

™ an excerption Utility, The inverse of merging (for obtaining a prescribed subset of the dam 
base), but reeds the same structure information. 


"■ a “tillr? Of representation, Suppose we want 10 re-represei>! the travel cost 

Ln forma Lien above a: 

gstp [BOSTON, FLICHTCOST] - [NYC <U&1 2 &. 37 > TORONTO <USI ...] 

getp(BOSTON r 6U&C05Tl - INYC <IJS» 1.3.75> ...J 
either because of a whim when changing gui own primary program, or sn order to adapt 
somebedy el Mi data to our program. Such a shaft should again Ihe doable by some utility, 
provided with descriptions of the old and new structure, and their relation. 

The list can easily be continued, It is trivial to write programs for such Operations, fo: each 
application ar each data base one has. But it is a bother, and one would prefer to have access 
to more general utility programs. More general programs are slightly harder to write, since 
One wants them to be usable for various higher-level data representations besides the 
elementary object.property representation. Depending on the desired flexibility of the 
program, a utility program may range from a hacking exercise to a hard A.I. problem. 

V,hen a (geneul) utility program is used, it must bE provided with a parameter-type description 
Df the data Structure that it is to Operate on. That description Can sometimes be integrated in 
the data itself, but often it ts desirable TO Write it separately, tike a «t of declarations for the 
data representation- In ibe litter case, it is also possible to Speed up execution by partially 

evaluating the Utility program with respect to the parameters as described in [Beckman ft al. r 
19741 

If ore has to Write out those declarations feu each utility program, then that also can be a 
considerable burden. But it ICEms that the same declarations or structure descriptions could 


serve several utilities. For esampk, irt the element ry representation where properties irt 
assigned [0 typed objects one needs information about: 
v which properties are carried by each type {used by data entry, dumping, and presentation 
utilities}-, 

v which structure Li e-spected for the property under a certain indicator (can be Used by 
almost all utilities, including those for presentation, checking, merging, rKccrption, and shift 
of representation. Also, it would be reasonable to eh-eck for appropriate structure during 
data entry}. 

* redundancy rules, for example For property inversion (used by the checker, as discussed 
above, and could also be checked Of generated on data entry); 

* fi" higheHevel da La representation: are used, such as contests, property assignments to new 
atomic carriers, or relational storage with pattern-directed retrieval, then all utilities need tu 
know about the storage conventions for that representation. 

Furthermore, Such a structure description for the data base is also part of the dttired user 
documentation for the data base. It is therefore a reasonable goal to have one common 
description Which can be used by all Utilities- and for documentation purposes. 

All pointi that have been made sp far apply hot only to LISP data basts, but also to 
con v eh Mona I, bulk data base:, and are in fact well recognized in the latter environment The 
L25-P environment does however Offer some additional possibilities. Most Importantly, the 

•K • 

description of the data haw Cah be stared in the data base itself, and Still be used by the 
program that operates on the data base To render this more precise, it is natural to consider 
the data base a: a coilaction of dfffd Wdc^j, where the description oF a data block Ji a new 1 data 


biCKk which ii also jn the data base. (The redrew terminates if some data block describes 
itselfl The structure description of a, data block will be Called its in (ti-Mock. Utilities can then 
usually be defined as operations on blocks, which u« (he mrta-blpck of the argument as 
parameters. 

The idea of data blocks is in fact useful not Only for distinguishing data from [heir 
description, but also for modularizing the ’primary' data (data which serve the purpose of the 
system, as opposed to descriptions) in the data base. A data block should Then be a chunk of 
data Which have a common structure and/or are doseiy related by some criterion. U could 
consist of a set of' tuples (- relations) which are Stored in the data base, or (in the elementary 
representation) Of a set oF property assignments {*» Tripks of carrier, indicator,, pioperty). 

A word of cautionr the term 'block' has some connotations in computing which are nar 
intended in inis context. No recursive resting of blocks or scope for identifiers is intended. It 
IS in fact often desirable to distribute the properties of an atom to several blocks. The primary 
intended association of the term 'data block’ is to the practice of organizing LISP function 
definitions into blocks or (Iks' of doseiy related function?. 

An cjinsrimemal system, called DAE A, has been instrumental in developing and testing some of 
these ideas, DAB A is a MACLISP program. The next section describes the data description 
and block structure in the DA BA system, and also discusses other aspects which would be 
desirable in a more developed system. Before proceeding, let US however add some hand- 
waving comments about this whole approach. 


From the theoretical viewpoint, the centra! June in. elm work u data baft description. Utility 
programs enter the picture because they probably oFfer the first practical usage of such 
descriptions,. but there are also a longer- range aspects to data base descriptions an A.I. First, 
automatic-programming and programmets-assistani type systems need not only program 
■descriptions, hut also data base descriptions. Whenever tlie program they generate or support is 
10 Operate OH a data base - and for A.], programs lhat is Usually the case, 

Ano,her reason :or wording at data base descriptions is Lhe need for methods of evaluating! 
comparing, and. relating the many proposed representations of ’knowledge* data, such as 
various 'semantic nets’. Again it is natural to compare with the situation for programs: Active 
work on the theory of computation for almost a decade* has provided a considerable body of 
knowledge about equivalence, complexity, and other properties of program*, Similar 
knowledge about data structures would be quire useful, just like for programs, mathematical 
logic can be expected to be gf some use, but nqt no cake us all the way, A concept of self' 
describing data bases might fit well into that picture. 

The idea of defining operations (such as. utilities) on blocks of data should perhaps be 
explored as a programming notation. Matrices (of numbers or other atomic entities) are a 
powerful notation in mathematics and ih programming languages such as AFL [3verson. IK21 
Also, one o: the advantages of relational data bases [Codd, lB'fO] is that they Enable one io use 
an algebra on relations [» sets of tuples], which has also been used for some formal query 
jangisager. The same idea might be useful for specifying search and other qua?i-parahell 
operations in LISP programs. 


2* Servicing utility operations. 


The DABA system un Bt Used in it least two trod ns. In the simplest mode, iHe user has erne- 
program, here called the primary program, which UWS the data base. A question-answering 
prograni is a standard example. As the data base attain? non-trivial sire, the user wants to use- 
some utility programs -on the data base He thcreroie has to write down a structure description 
af the data haw he already has. DAP.A Is a system For representing and maintaining such 
descriptions in a systematic way, plus a collection, of utility programs which use the 
descriptions. In the case discussed here, the primary program and the data base existEd before 
the DAE A facilities were called in (The other mode oF using the system is for managing 
data-driven programs, and will bed bussed Jn the next section). 

Let US choose a specific example and then describe how Jn structure would be described W the 
DABA system. We must here select a very simple example, which uses an object-property 
rep reien tat ton., in order to concentrate on the description, The DABA system is however 
useful] For data bases with a richer structure as well. 

Consider a block of property-list data about cities m the eastern United States, The block ts a 
sc', of property assignments, or triples, such as 

UBOSTON, INSTATE* f1ASS>, 

<BOSTON P SUBURBS, (LEXINGTW, REVERE,..* )>, 

<NYC* INSTATE, NV> + 

-cat 

<flASS t HA5C1TIES, (BOSTON, LEXINGTON, 

<T!A5S* RJLLNAnE, nASSACHilSETT5> t 

... 1 

which of course says that Boston Ji in the state oF Mass*chuselts, and so on. Indicates. 


COTl tiiuiation and is not intended to be in the data base). Each data block has. a norm, which 
may h? atomic (but does not have to be). Let the atom US-EAST be the name of the above 
block, 

A QLlSP-like nutation will be used, with angle brackets <„> for tuples - lists, curly brackets j._) 
for sets, and square brackets I..J for free property I is«. A property-felt III vi L? v2 _.] is a set of 
assignments of vk to ik, so the square bracket expression is really an abbreviation for 
{<tl vbyqi v2>,._ l 

LISP function definitions will be written with round parentheses All these types- of 
parentheses are assumed to map into ordinary parentheses in the actual implementation- In 
Other words, the knowledge that a certain list represents a set rather than a tuple, is not assumed 
to be available in that item itself. 

It will be more convenient to specify the contents of blocks using the access function 
dgstpfc, i t nj, where c is a carrier, i an indicator, n a block name, and the function returns 
the corresponding property-value. The block contents above can therefore be described as 
dgetp rao&TTlN, INSTATE,US-EfiSH * ftA55 

dgetp [0<JSTDN,SUBURBS,US-EAST] - SLEXihfGTQN. REVERE, +*A 

+ i 

The description of a block in DAB A consists uf two puts. Consider a data block (of which LfS- 
EAST is a toy example) and a program which uses the block, as a data bale for question 
answering or same similar purpose. One could write down several different bbtks, using the 
same conventions, and the program w'ou-td then presumably be able to use any of these blocks. 
The dticnplitm of tiprtitumion Shall contain a specification which is common to. these blocks, 
and which therefore encodes some oJ the conventions that are assumed b-y the program. By 


conirast* the dtstription of fxfnil amt* ini 3 catalogue of the ten sane.! of each block, arid other 
information which U local to the biotic. There are several reasons for making such a 
distinction: economy of storage for [he shared part of the description 15 an obvious reason. 
Also r the previously mentioned possibility of partially evaluating a uulity or other parameter- 
driven program with respect to the data has* descripiion, is only worthwhile if the part of ihe 
description that is being kept fixed. can be fattened out- (There arc however also ways of 
avoiding the distinction, in special cases when one does rmt want to make it). 

The common denominator for the two descriptions ts the Serfs. In the present example, one 
immediately r«ogrm« different sons of carriers: CUV, STATE, etc. The description 
entenc for a block includes a catalogue cf the earners in each of the sores* represented aj: 
ngetp [US-EAST*NODES] » 

[CITY IBOSTOH* NYC,,,.I, STATE MASS, W, I 

while the description of Structure includes the information of what indicator! are used by object! 
lh each sor*. for example that objects of type CETY may carry properties under (he indicators 
INSTATE* SUBURBS, etc. 

The function ngetp is used for getting properties of blocknames, m rhe description of the 
bfoeks extEnt. The function nay sometimes su-nply make an access in the property-list of its first 
argument, in which case it is synonymous to the INTER LT&F gstp. but it may aho compute its 
value by default from, an appropriately Stored procedure, handle non-atomlt block names* etc, 

The description of extent also includes information about the location of the block, for example 
AS global property-lists', 'as propertyrttsts local to this block’, or 'as text file with name ,, r ", The 


first case Ls ex.pres-sed ai 

ngetfi [U5-£ft5T f ATLDC) - GLOBAL 

The conventions used in the description of extent are ro some degree arbitrary. One mighr 
prefer to split up the NODES' property so that the set of sorts is obtained in one access, and the 
set of carriers in a sort is obtained m one access for each sort. Such changes would not be 
significant. 

The meta-block of OS-EAST (■ its description of representation)' u another block, whose name 
might be Cl TIEo. The relationship is indicated by 
gotpEUS-EAST,PIETA] ^ CITIES 

Some minimally needed information in the meta-block is, first, which indicators are carried by 
objects in each sort in the described bit**. Thus, since BOSTON and NYC have properties under 
the indicators INSTATE and SUBUfifiS, and Since they are in the sort Cl TV, One should have: 

d ge tp ICITY,CARRpROPS,CIT 3 ESI » i INSTATE.SUBURBS,... } 
and likewise 

d s etp[STATE,CARRFRDP5,Cl TIES! - iHASC]TIES,HASCAPITAL,...| 
and 50 on, 

The mera^block should also contain information about the expepred structure of properties, in our 

example, we know that properties under the indicator INSTATE shall be atoms of the sore 

STATE, rhaf SUBURBS properties shall bE sets of cities, and so on. Such conventions could be 

encoded in a straight-forward fashion as 

djotp [INSTATE,PRQP5TRUC,CtlfESI * *5GRT S!ATE> 
dgetp [SUBURBS,PROPSTRLJC,CITIESJ . <5ET -cSORT C3T¥» 


In QUr simple example, all names (block rilmes* earners, indicators, sort nantes, etc_) have been 
aiOTfli. That is however noi necessary, and in descriptions qf less trivial rep resell lal ions it is 
frequently useful to let them toe non-atomic. 

The meti-biock contains information which might occur as declarations in some other 
programming languages, and in the data description language of a management system for 
large data bases. The important difference is that here the meta*des<fjptton is a new data 
block., so that the user can use and extend that information according to has own needs. For 
Example, IT would be natural to extend The meta-block with information which relates rbe 
imitives for .his da,3 block (sprtj and indicaiorSy in this simple example) to Liser’-prienfedl 
concepts in a model of the intended application. 

In The actual system, each block may be associated with a number of ’satellite' blocks which 
provide additional bu: optional information. User additions to a meta-block are usually best 
organised as a new satellite block, rather rhan as a change in the original meta-block, Even the 
PRDP5TRUC property k actually kept sn such a satellite block. 

Very Often one wants to define access procedures for properties, which compote the property 
from other data in the system, looks up default values, stores properties in alternative lercatpani, 

etcetera. The meca-block therefore always comams an access fundtm for each indicator, for 
example AS: 

egetpClNS TATE, ACRE’S 5FN, Cl Tl ESI - KGETP 

where xgetp is Che default access function which does a trivial (explicit) look-up. Suppose 


however that one would want to define a block US-EAST2 as an Update of US-EAST, so that 
properties in US-EAST2 use properties in US-EAST as default. The block US-EAST2 would be 
described Similarly to US-EAST, with the following amendment?: 

(]} ngo tb IU5-EA5TZ, TIPD f F OF ] = US -EAST Thus property assignment belongs (0 the 

description of ex Lent of U5-EAST2. 

(2) ge fcp [US-EAST2,flSTAl * CITHQU* US-EAST2 needs a different description of Structure. 
(In practice, Us meat-block would have a non atomic name, but we assume an atomic name here 
for simplicity), 

(5) dgetp [INSTATE,ACCES5FN,C| TH003 - 

[LAndPA (C I N)(OR (XDETF C [ N) 

[DGETP C I (NGETP N ’nDDIFPF)} M 

and similarly Tor every other indicator that wju assigned an access function in the old metn- 
block CITIES. This access function takes ihc same arguments as the function dgotp It first 
checks if the property exists explicitly in the block that is mentioned as third argument, and 
Otherwise looks it up in the default block. (In the actual system, access functions have a fourth 
argument, and can be used fo 'get', 'put', ’delete", and "change’ operations). 

The block CtTEES, which is the mcta-bkjck of US-EAST, should also in its turn have a meta- 
block and n catalogue (description of eateni). The sorts in the block CITIES arc SORT 
(containing the carrier? C I TV, STATE, etc.) and INdTCATOh (containing the carriers: INSTATE, 
SUBURBS, HA5CITIE5, etc). Thii structure t$ Correctly described if we have 
getpICITEES,HETA] - DrtEGA 
dgetp [SORT,CARRFROPS,OhEGAl > inARRPdOPSl 
dgetp[INOtCATOR.CARRPRDPS,ONEGA] - (ACCESSFN FROPSTRUCi 


plus the appropriate properties on AECES5FN and PRUPSTRLfC. It is then correct to deFine 
petp[OMEGA T HETAJ * OMEGA 

so that OMEGA describes itself In general, proceeding from a blocks to (heir meta-blocks, one 
alwa/s eventually reaches OMEGA, but oFten the path :s longer than in this example - The 
definition of the NODES properties for CITIES and OMEGA are straightforward, 

What has been described JO far Ls a basic description system, which might be sufficient for data 
blocks that use simple representations. In an environment where the user has already designed 
his primary program and his daLa base, he has to set up the description of representation as a 
pQt! factum description of the conventions he has made, If he needs nontrivial access 
functions, he has to Write them himself, although with skilE And luck he may be able to define 
them as smalt interface procedures that call appropriate parts of his primary program. 
Similarly, the NODES property (■ (he catalogue) in the description of extent can sometimes be 
computed when needed, from information that has already been ter up by or for the primary 
program, and Otherwise the user has to create it, 

Such a basic description is what is needed by utility programs as discussed earlier. The intended 
purpose of rhe DA&A system is partly to provide a coordinated set of such ucilicy programs, and 
partly to provide 'canned' higher-levei descriptions. For example, in specifying the block 
CITMOD in the last example above, the user should only has to Specify that It modifies 
CITIES {expressed by an appropriate property assignment to the atom CITMOD), and that the 
me^a-biock of Cl. MOD is e,g. MODIF, where M0DIF would be a mefa-meta-block which 
imposes the appropriate defaults for access functions, NODES properties, etc. in CITMOD. 
Sjmt.ai mera-mcta-blocks arc or should be available for other common operations inside arid 


between data blocks 



3* PrDgra.nl/eliita base integration. 


The DABA system is not particularly helpful for developing conventional programs. It u 
however relieved to be useful when one use.! an often uied, but tittle recogriired programming 
technique shat I call dala-driven programming. In (his section I argue Shat data-driven 
programming is a significant development, and much more than a hack; and also that a 
HA BA-type system can facilitate the use of this method 

A common model for a program in LISP (and most other languages) u that the program is a set 
of procedures which call each Other. Each procedure has a name. A call from a procedure 
FOG to i procedure FIE is manifested in that the definition of FOO explicitly mentions the 
name FIE. -Such a textbook model Of programs li not always applicable, Many programs arE 
organiied as a col lection oF procedures each of which is attached to data Hems Jn a data barf, 
plus perhaps, one part which is an. ordinary program. In such a program, a procedure f may 
sometimes process its input data, fey calllhg procedures which are attached to them in the data 
base. This constitutes an indirect or data-driven call from the procedure f to a procedure g. 
Usually the procedures or program fragments are stared as properties of atoms, but they may 
appear anywhere in the da La base. 

A data-driven program then consists of some ’ordinary' procedures, and some 'data-driven' 
procedures which are invoked through, data-driven tails. In must programming languages it is 
difficult or impossible to implement dasa-driven programs, except Of the very restricted kind 
that are obtained in can statements where the driving data are integers {Fortran. Algol 6a) or a 
set of items chat have been explicitly declared in the program (Pascal), Ir u easy and 


Straightforward CO implement data-driven programs with full generality in interpreted LISP, but 
this programming practice u rot fully recognised: INTER LlSP's maktfil* system tTeudman. 
197-1] provides a Sot of service in keeping crack, of compiled code, but assumes that it is stored in 
the 'function cell' of the atom, ]n MACLISP [Moon. ]074] the compiler has only very recently 
been provided, with an option that allows it to compLle functions that are not EXPR or FEXPR 
properties. One should not treat data-driven programming as l ‘hacV' l thereby implying that it 
should bur discouraged, or that it lacks research interest, It is a powerful programming method 
and program structuring method Tot the following reason.!; 

— Pnwedtij-rj obtain Irirfy meaningful names In data-driven programs, each procedure is 
Identified hot by a single rame, but by a combination or such. Fas example, procedures that 
aro stored directly on property-lists are identified by pairs of aioms. Therefore, Che identifier of 
a procedure can be more than 'mnemonic 1 : ot can state the purpose of the procedure in a 
fashion which can be used by Other parts of the program. 

For example, McDonald 1 ! bibliography program [McDonald, 1975J assumes that each biblio¬ 
graphy entry is associated with a number of properties such as AUTHOR, TITLE, etc., and 
each property name has on US property-list procedures for read Eng, printing, etc. tbit property, 
The procedure that ii identified a g 1 ec[ AUTHOR. PR 1NT-UP-FN] has inch a better-than- 
mnemonie name. The routine which goes through all desired properties of an item arid applies 
the- reading procedures of each indicator, use! the meaning embodied in the 'name'. 

” Factitious atUo^orfr program gtYitraUtfi. If program gene ration is to go beyond the level of 
toy programs such as trivial sort routines, the generator must use a model of the program that is 


being generated The tasl of specifying Che model, and even more the tajV of relating the 
model to the program, are particularly Simple fen data-dliiven programs. The actual program 
generation tan then ofLeri consist of generating individual data-driven procedures or code 
fragments. The latter taw arises if each data-driven procedure has the form 
(LAMBDA (X -KFQO (code 1) (code 2)... (code n») 
where each expression (code 1 } has been generated separately, and where the function FOO is 
the 'glue' between the programs and is responsible for communication between them. (FOO 
may he a built-in function such as OR or PRGGN.or 1 function Written for the purpose}. The 
PCDE system iSandewall 39TE, Sandewafl J973, Haraldson 1974] uses this method for program 
generation, 

— Uses the appitai!l<m fangitagt, anri wdRfi ft eerf/y eXtmilbit. The notation Chat is input to a 
program is or should be a language which is natural to the application of the program. The 
same holds for the notaliOftll Conventions that are used in a data base, in both cases, a 
program which is organised around such an applet jon-cnemed notation is likely to have * 
good structure, and extensions to the program immediately reflect extensions to the application 
'language'. 

Interpreters are a classical example nf data-driven programs. Interpreters Tor conventional 
languages are data-driven with respect to procedure names (i.e. data of the interpreter). Recant 
language features such as paiiem-dirEcted invocation and derwns also assume that procedures 
are indexed from data Structures, although in this case the data of the interpreted program. 
The apparent power of the latest generation of A.L languages IBobrnw and Raphael. 19^} is 
perhaps largely taue tn the fact that they made data-driven programming available to users who 


did not think or using il explicitly, The claim here is thai it ts often bFrter for [fit Liser to 
develop his own scheme f« Organising his prog ram (in the sense of Storing the procedures in 
•.he right places) instead oF using a single package of high-level devices. There arc also several 
examples of successful data-driven programming around. The S-HKDLU program [W,nograd, 
I975 j can be used in support of many claims; it is aLso data-driven in several parts. 

The reason why this whole discussion is brought up in a paper about data base description, PJ 
that data-driven programs allow procedures to appear in arbitrary positions in (tie data base.. 
There are often plenty of relationships between procedure items .and olher itrms in the data 
base: procedures may have been generated from other data, and program analysts programs 
may ofitn generate data about programs that should be stored in the data base, so chat ril does 
not have to be re-gcneratcd repeatedly. It is then natural to use one's data base management 
system tor managing programs and program descriptions as well. 

The contrast between the situation described here, and the situation described in the previous 
section, is characteriaed by figure t, In diagram (a), the large triangle is the primary program, 
the small triangle the utility programs, and the data base is dserlfcwd by the DAB A system for 
the utility programs. In diagram Cb}, the primary program consists mainly of data-driven 
procedures which are also managed by DAB A. 



(a) 













There is also another reason: the data, rhat data-driven procedures are associated with. can 
sometimes he 'object' data for the system, but very ofien it n natural EO choose them as items 
that appear in the self-descriptiOn of the data block, for example indicators Ot 40 ft names. 
Thus the descriptions Of a data hkock are often an appropriate framework. fa: organizing the 
program, 

Most Utility programs can wilh advantage be data-driven. For example, a presentation utility 
COU)d be driven by printing procedures associated with properly indicators. This is a, 
commonplace Idea, but raises some practical problems. Consider the following scenario: we 
have acquired a large data bass (large by A.|. standards, Shat is), consisting of several block* 
with different structures. We are also using a number of different uillttics, each of which 
drives specialized procedures For all or some of the blocks. Furthermore, descriptions of the 
data blocks sic around and are directly interpreted by several of the utilities, and are used for 
generating specialized procedures for seme others. Suppose now Chat we want to move this 
battleship a bit, for exampiEL (a) modify the structure of some data block, ft) delete a data 
block, (e) discard a utility. The first operation implies a number of other changes In the Systems 
the other two enable nan-trivial garbage collections. )n a large system with a considerable liFe- 
length, such garbage collections are necessary (even if one has infinite memory, he still wants to 
know what is garbage so it does not have 10 be updated). 

In order to Support such such Simple operations, and also in aider to support the user who wants 
CO understand the sysreffl, SO Lbat he can perform more complex operations On it, one needs a 
model of the structure of the system. Here again the (block structure and other concepts in 


tiABA are useful. 


LcC us exemplify that, again with a simple fnample. Consider a pretty-printing utility program 
P, which operates on a daLa block B whose meta-block getp [B.ttETAl - n, The program p 
makes Use of Spetlaliied printing procedures And other parameters which apply to all blocks 
which hke B hav-e the structure described m II. These parameters [Ogether constitute A data 
block HP. ■, [ hey migh: be included in tl (rseif, buL it is not desirable to clobber M with auxiliary 

procedures for all utilities, and therefore we prefer !o let each utility define its own 'satellite' 
block ta H). 

The block HP has the same sorts and the same catalogue as rl, but uses different CARRFRQP5 
assignments. For example, m our initial geography example. the block n contained PftQPSTflUC 
arid ACCt$SFN properties, for HASCSTtES and other indicators used in EL The block HP would 
contain a PRSNTFN property for HASCinES, which P then uses, The relationship between DP 
and fl should be expressed by a reference such as 
rgatpDIP,DESCRIBES] - M 

This reference should imply a default value for the NODES property of HP, 

j he muta-MocA for HP must be a block which describes the structure of the parameters that the 
program P assumes, i.e. it jj part of the documentation of P In the present D.ABA system, 
utility programs are integrated; with their specificstioit, so a data-block P contains both rhe set 
of procedures Chat make up the utility program, and Lhe information tbit makes P a suitable 
meta-block fpr HP. For example P contains A reference to the knowledge about how to compute 
the NCLtE property of HP from its DESCRIBE!: property, (Actually, Char knowledge is conveyed 
to P by itj meta-block). he structure of these blocks ii illustrated in figure % 
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FIGURE 2 
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Thiis example Illustrates how blocks of data Art 004 merely clusters wj[h dense internal 
connections: there are also relationships b-eween blocks, such at the rtETA relation, the 
DESCRIBES relation, the H0D1FQ? relit ion (used in an example in Ihe previous section). 
Several ocher relations are important, such as the relation* between a program, the block of data 
•hat was input to it, and the block of data that it produced as result. Relations between blocks 
arc macro-level descriptions, which complement the micro-level, declaration-! |fpe descriptions 
such as CARRPftDFS or PflCPSfRUC properties. 












4- Generation of procedures, 


The I>ABA system as such, assumes that data base descriptions contains procedures, namely 
access functions, and specialized procedures for various utility programs. In addition, many 
appheationi may involve data.-driven programs as disoussEd in the previous section. 

Where do These procedures come from? The simplest case IS of course where they are always 
written by the user- There are however several ways whereby the user can be relieved of this 
responsibility, or it least Of some nf the drudgery invoiced. 

One obvious method ss by default cornpLitatiori. If the procedure does not exist, then it Is 

computed by a procedure which may derive It from other dill, ask the user, ert. This is 

accomplished in 4 simple and uniform fashion in DABA through a remrslw acccis-funetum 

tfiffWtsrra. ThE function dgetp which was used in section £ to obtain data from the block 

USC1T S ES, is defined approximately as 

dgetp le* i, nl - 

if n=Ot1EEA Chen ys Lp to, i 1 

el ss sp£ly{ dgetp[i,ACCESSFK,gotpEn*HE?AlJ, 1 i a t tc t i, n3 3 

In other words, in order to dgetp the HASH TTE5 property of HASS., one retrieves and uses the 
ACCESSION property o( HASCIT1E5 in the meta-block. But for that, he must retrieve the 
ACCEESFN property of AtCEEEFN in the meta-meta-blotk, and SO oh. fAt least theoretically; the 
recursion u sometimes Shortcut). The recursion terminates at the ultimately 'meta' block GHEE A. 

This mechanism is a flexible way of defining appropriate access functions. For example, in 


MCtion ^ we oiscussed the modified data block US-EAST2, which modified (he block US-EAST, 


and where 

getpCUS-EASTpflETM - CITIES 
go tp [US-EAST2,METAi = C1TMDU 
ngstpIUS-EA5T2,HQD1FDF1 - US-EAST 

Here che user should no; have to write out the access function* fw CITMdD. Instead, there 
should be a data blodt flDSD which describes modification blocks in general,, so that 
ge t 0 IC [ TI1DD. HE TA 3 - MOD. The access functions in CITflOD aTO obtained 3S 
agetp [ACCESSFN „ACCE'5'5FfJ r H0Dl, and might he the one oullined in section 2 . or (improved) 
the following: go and get the access function for the same indicator in the block CITIES. Try 
□sing it in the current block (in this case, U&-EAST2). If no result, then make an access in 
dgetp[current block, MQD3F0F], 

In fact, all other syjrem properties, for example CARRPRDFS. are accessed in the same way tiling 
dgctp, It is therefore not necessary to inverts a new atom as a name for Cl TflCD. Its name is 
chosen as [MUG Cl 7 IE'S!, whereby it is implicitly specified to be a block whose met a ii MOD And 
which modifies the block CITIES. (The actual DAB A nutation Is slightly different). In 
general, the method of defining properties of blocks through access functions tn Lhe meta block, 
complements well the method of using non-atomIc (’molecular*) names for blocks, where the 
contents of the block, or at lean some of the consents, are implicit in the name of the block. 
The advantages WLth ngn-atomic block names are analogous to the naming advantages of data- 
driven programs. 

Utility programs which use specialtied parametric procedure? also access them with the function 
dgetp, which means that the same kinds of default mechanisms can be Used for their 


parametric procedures such u PRlNTFl*. The recursive UCttS irrtChanism is quite powerful, and 
eriAbles one (0 implement a number of desirable facilities with a, very small kernel system. Its 
major drawback is that higher-order access functions of access functions are usually less than 
transparent to read and understand. Efficiency may alio be a problem, Which hopefully tan be 
handled by .saving access functions so they only have to be computed once ('memoiiation'), and 
using; automatic simplification of the lower levels of access functions, 

Sometime* a procedure Ls to be built up and modified m several successive steps. St must then be 
initialised in seme way (for example by its ntcta-levil access function), whereupon it Cart receive 
sd[iiS« Which successively modifies it. For example, if a. data-driven procedure contains or 
refers to a set of theorems or demons that are to be triggered by the indexing data, then each 
advise might contribute one more theorem or demon to the structure. A program for 
simplifying LISP expressions might associate with each LISP function a simplifier procedure 
for forms where it ls the leading function, A new simplification rule, such a; 

{car (list ax MW) -> IX 

would then be sent as a message to the simpiifier for CAR. (The REDFUN program [Sardewall 
197t r Beckman, et a\ iEfal works in this fashion). ■ Sometimes the advise that is given to a 
procedure is less uniform, INTERLiSP [Teitelman I9T-41 contains facilities for user-specified 
advise to the entry and exit parts of arbitrary user procedures. 3n the DABA system, it IS 
frequently desirable to let various items send ad vise to an access function or class of acce« 
functions, telling it where to find explicit and default data, whether and how to 'mcmoiur 1 
computed data, and so on. 


Several of Hewitt’s a ctor ideas [Creif and Hewitt, carry over to this purpose. What we 


hive called advise is a kind of message Giving advise is hke an actor ’handshake': |he 
receiver of the messages must he the one who knows hnw to incorporate l( into his infernal 
Structure. There is a need for actors in the sense of objects which both receive and send 
messages Bui chains of messages which trigger each other are here cmiy a secondary purpose; 
the primary purpose of a message is to modify a procedure or other data item. Abo, it is 
mandatory in our case to have an opLian for saving a protocol of which roes sages were itm 
where, so that later changes early in i message Cham can perpetuate along the chain. Such a 
protocol should of course be stored as anothei data block, in line with the general philosophy of 
the system. 

In fad, the data structure becomes cleanlier if messages are sent to blocks, rather than to 
individual procedures, Thus a simple mera block might receive messages saying 'tell all your 
access functions to pick default values from the block B' or 'tell your access function lor 
5UBUHBS to get the explicit value, and filter away from it all proposed suburbs which are not in 
the same state 1 . The structure of the blocks involved should be as follows: 

B block 10 which messages are sent 

n aetptB.nETAl 

BA block of messages that have besn sent TO B 
A getp [BA,METAl 

Here A should contain the information about how to interpret incoming messages,, and it should 
be on the same level as ft In other words, if B and B’ have rhe same H, and BA' ls like BA but 
for B h , then BA ana ESA’ should be able tp share the same meta-block A (figure 3). 
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FIGURE 5 

















The previous mentioned methods for defining blacks through their meta-blocks, .sometimes 
using nor-atemic block names, are useful for protocol blocks as well, Protocol blocks are 
actually given non-atomic names such as [PROTOCOL B) rather than UA. The HE IA of this 
block is then implicitly Pfr&TOCGL If rt has an idiosyncratic structure, then a corresponding, 
tailored meta-block for protocols will be needed, i.e. FMTOCOL Is really {PHDTQCOLk l“l)„ and 
what we vistfd to call BA ha? a name of the form [ [PROTOCOL#- n] &p, The met a-met*-block 
PROTOCOL* computes parts of the protocol meta-block (PHUTDCOL* HI from n 

Protocol met*-blocks such as PROTOCOL or (PROTOCOL* Ml alio contain ihe decoders for 
incoming messages, Each transmission of a message is called an fiwnf. An event knows what 
message it conveys, its source, and its destination (where both of Che latter are block names). 
The event is also a member or the prOLOCbl blocks of its source and its destination, although 
with different properties in those two. A Simple executive seeps track of a queue of events, and 
for -each event looks Up the decoder in the protocol block of the destination block of tliac event, 
and applies it. 

This message-sending Facility is net intended as some kind of programming system, If the 
DAE A system is used as in section 2 Of this paper, then it does noC aFfeet the user's primary 
program at alL It is intended as a mechanism for performing and keeping track of updates to 
the data base (including daia-driven- procedures), so that later changes in the data base (cn the 
MpaLry sens* of the word) obtain appropriate secondary effects, Also, messages are 
only Stfli 'to procedures’ (loosely speaking) for changing them, not for invoking them. 


5. Other aspects. 


Some aspects of the DA BA lyitem have been more nr \m ignored m thii paper. We ha ire 
remarked that each b-lock needs a dtscnpuon. of structure, and a description of extent. The 
dpscrrp.Lon of structure i» tit rneta-tjlock, and hat l!i mcLa-block, and 50 on. The description of 
extent, or catalogue, it at lea.it in SimpM cases the set Of properties of the b sock name, But it 
alio needs a rnera-bloclk, where for example the access function for the name's NODES property 
is located fin the cases where the MODES property is computed from ocher information). THe 
meti'block of a block B, and the meu-block of the catalogue of B are not in general identical, 
but the tatter is derivable from the former Also, Che catalogue block oF the catalogue block is 
computed as needed (storing it explicitly would lead to an infinite regress). The resulting 
structure is powerful, but umurtunately also tends to become fairly complex. Later generations 
of the system will .attempt to simplify it. 

Another aspect which has not been covered li the relationship between the description structure 
of DAB A on on? hand, and problems in the representations of knowledge, such as IS-A link 
problems and frame systems (Minsky 19M] on the other hand, Information Ifi DA&A meft- 
blocki 4Uch as CARRPR.OFS and ACCESSED information corresponds vaguely to what one 
needs in those cases, hut the corresponds nee is not trivial 

DABA is presently a MACLISP program, although it should be relatively easy to transfer it to 
other LISP dialects. It contains Simple utilities for data entry. Checking, dumping, and 
presentation. The utilities are data-driven and their structure is described within the system, as 
described above. The current system also contains facilities for keeping track of all blocks; and 


a few general-purpose facilities 5UCh as comment blocks (for arbitrary other blocks) and update 
blocks. The message-sending faciliTF f«r updates of procedures lus. been specified and is 
probably the next tp be implemented, After that, the present implementation wj|| probably have 
served its purpose, and the nest generation of DABA will he due. 
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